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REMARKS/ARGUMENTS 

Reconsideration of this application is respectfully requested. 

The Examiner's objection to claim 6 under 37 C.F.R. § 1.75(c) is respectfully traversed 
and reconsideration of same is requested. Claim 4 is explicitly directed to a single node "for use 
in a communications network of interconnected nodes' 1 . That is, the claimed subject matter of 
claim 4 reads on a single node in such a network. Dependent claim 6 clearly adds further 
limitation to that subject matter by claiming a communications network comprising a plurality of 
such interconnected nodes. Claim 6 has been amended slightly above so as to make this 
intention even more clearly apparent. As such, it clearly meets full compliance with 37 C.F.R. 
§L75(c). 

The rejection of claims 1-6 under 35 U.S.C. §103 as allegedly being made "obvious" 
based on Rahnema '729 in view of the applicant's "admitted" prior art Newbridge WO '005 is 
respectfully traversed. 

The present claims specifically recite that the message (Setup Request) has an additional 
information element for containing the identity of a "Virtual Source Node'Tor the route setup. 
Rahnema discloses a header 72 which "carries data identifying a type characterization to be 
associated with packet 70, a length to be associated with packet 70, and any other information 
conventionally included in data packet headers" and a routing code 74 which includes a 
destination satellite number. In Rahnema' s virtual path embodiment, the packet includes a tag 
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(presumably within the routing code 74, as it is not "conventional information"), which identifies 
a source-destination pair. 

This tag in the packet is inviolate. It is not changed when routing becomes blocked and 
crankback occurs. 

To help understand the distinction between claim 1 and the hypothetical 
Rahnema/Newbridge combination, consider a Rahnema-type routing applied to the example 
routing in the applicant's specification. 

When Node S handles a new message, it will retrieve the tag X (corresponding to the pair 
S/D), and refer to its routing table for the entry for X. A Rahnema-type routing table will contain 
a primary route, a secondary route and a tertiary route (but for the purpose of comparison, 
references to the tertiary route will be omitted). Node S will route the message to primary route 
node A. 

When Node A receives the message, it will retrieve the tag X, and refer to its routing 
table for the entry for X. It will route the message to primary route node B. 

When Node B receives the message, it will retrieve the tag X, and refer to its routing 
table for the entry for X. It will try to route the message to primary route node H, but this fails. 
Node B will now retrieve the secondary route from that entry for X, i.e., the source-destination 
pair, S/D, and will try to route the message to secondary route node C. 

This route also fails, so, in accordance with Newbridge, node B will send a Release 
message to node A and include a crankback Information Element in the Release message to 
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indicate Crankback (as opposed to normal call clearing). Node A will now try sending the 
message to the secondary route node G in accordance with its routing table entry for X. The 
header information of the message itself is not changed at any time , so node G accesses its 
routing table to find the entry for X. 

A similar routing situation in accordance with the present invention will now be briefly 
described with comments as to the differences with the foregoing Rahnema-type routing. 

When Node S handles a new message, it will retrieve the value from the virtual source 
field (i.e., information element) and the value from the destination field to make a virtual 
source/destination pair, which in this case is S/D, and noting that it is to act in source mode, it 
will refer to its routing table for the entry for S/D, and will route the message to primary route 
node A. 

The Rahnema tag is constant throughout the routing process, whereas the content of the 
virtual source field is dynamic according to the routing history. 

When Node A receives the message, it will retrieve the virtual source/destination pair, 
S/D, and note that it is to act in transit mode. It will ignore its nine source mode entries (AS, 
AB, AC, AD, AE, AF, AG, AH, AJ) and look in its transit mode entries for the 
source/destination pair, S/D. Transit mode entries have only a single pre-allocated route, in this 
case the route is to node B. 
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When Node B receives the message, it will retrieve the virtual source/destination pair, 
S/D, and note that it is to act in transit mode. It will look in its transit mode entries for the 
source/destination pair, S/D. The single pre-allocated route is to node H. 

Node B will try to route the message to node H, but this fails. Node B will now change 
the content of the virtual source field to "B", and re-process the message. This time node B 
recognizes that it is to act in source mode for the virtual source/destination pair, B/D, and 
accesses its routing table by the pair, B/D. It is important to note that at no time does Rahnema 
change the value of the tag when accessing the routing table , whereas in the present invention, 
node B is now accessing its routing table in respect of a pair B/D, which is different from the 
original pair S/D. 

Node B retrieves the unused route from the source routes, in this case, the route to node 
C. If this route were available, it is important to note that the message received by node C would 
contain the virtual node B, so node C would act in transit mode and look for the transit mode 
entry for B/D. In a Rahnema-type arrangement, node C would still access its routing node in 
respect of the pair S/D. 

Consider now that the route to node C also fails, so, in accordance with the present 
invention, node B makes a change to the virtual source field of the message to make the virtual 
source "A", and sends the modified message to node A. 

Node A will retrieve the virtual source/destination pair, A/D, will recognize that it is to 
act in source mode for the virtual source destination pair, A/D, and access its routing table by the 
pair, A/D. It will then send the modified message, now indicating that the virtual source node is 
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A, to node G. Similarly, node G will access its routing table in respect of the pair A/D, in 
contrast to a Rahnema-type arrangement which would access in respect of the pair S/D. 

Specifically, Rahnema does not disclose a virtual source information element (field) as 
recited in claim 1, contrary to the Examiner's assertion that this is disclosed at column 15, lines 
50-64. As there is no virtual source node identity, Rahnema cannot disclose a step of comparing 
the node identity with a virtual source node identity retrieved from the message, and cannot 
disclose a step of accessing a routing table in accordance with such a retrieved virtual source 
node/destination node pair. Rahnema does not disclose that a failure in a transit mode attempt 
results in the node overwriting the content of the virtual source field with its own node identity 
of the node from which it received the message. 

There is no suggestion in Rahnema or Newbridge that the skilled person should consider 
adding a new field to contain a node identity which will be treated as a source node and which 
will be changed dynamically as route failures are encountered. 

To repeat, the hypothetical combination of Rahnema and Newbridge does not disclose or 
suggest all the features of even the independent claims of the present invention. 

Dependent claims 2, 3, 5 and 6 add yet further patentable distinction. In view of the 
above discussion of the substantial deficiencies of the cited prior art, it is not believed necessary 
at this time to further discuss the deficiencies of this art with respect to such dependent claims. 
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Accordingly, this entire application is now believed to be in allowable condition and a 
formal Notice to that effect is respectfully solicited. 



LSN:vc 

1 100 North Glebe Road, 8th Floor 
Arlington, VA 22201-4714 
Telephone: (703) 816-4000 
Facsimile: (703) 816-4100 



Respectfully submitted, 



NIXON & VANDERHYE P.C. 
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